If this PR is accepted, it paves the way for, in my opinion, a very useful feature.

Currently, we can use state.set() in pyscript. However, this has several caveats that go with it:

1. the entities it "creates" are not restored,
2. existing entities with the same entity_id are blindly overwritten,
3. these entities cannot be managed (renamed, etc) in the Home Assistant UI

Using Config Flow and the appropriate Home Assistant Entity Objects, pyscript could support pyscript.binary_sensor.create() and pyscript.binary_sensor.update() as well similar methods for sensor to allow for pyscript automations to actually create entities/devices in the Home Assistant way.

This Code which allows creating of such entities/devices over websocket commands for use with Node-Red should provide a good example of how this is done.

Thanks for this PR! It looks good. Yes, there was no good reason to have the user create the pyscript directory - I saw that python_scripts did it that way. Thanks for adding tests too.

I ran pylint and got the following warnings:

************* Module pyscript.config_flow
custom_components/pyscript/config_flow.py:19:4: W0222: Signature differs from overridden 'async_step_user' method (signature-differs)
custom_components/pyscript/config_flow.py:19:4: W0222: Signature differs from overridden 'async_step_user' method (signature-differs)

@dlashua reported and I've confirmed this issue.

This PR has broken the initial loading of config settings. It used to be that the config_entry argument to async_setup_entry() contained the current yaml configuration, starting with a top-level entry for pyscript. The load_files() function extract's pyscript's apps config with:

apps_config = config.get(DOMAIN, {}).get("apps", None)

That's now None for two reasons:

• config_entry.data starts below "pyscript", not at "pyscript"
• config_entry.data is some old setting - it's not the current yaml configuration

On reload it works correctly since it explicitly loads the latest yaml config with:

config = await async_process_component_config(hass, conf, integration)

That might be an expensive operation, so I'm not sure whether it's ok to do that on startup.

Thanks for the heads up @craigbarratt clearly missed some things. I actually think the way that reload is working would not work with config entries. We shouldn't be loading data from the config, we should be loading the data from the config_entry. I've already fixed the issue I think, I just need to figure out how to resolve the reload before I submit a new PR

I actually don't understand how config flow works, and how the configuration is stored. Can you mix yaml with new-style config?

The reason this is important is that just before your PR, I committed a change that allows other config parameters (below pyscript) to be available for pyscript apps and scripts.

So I guess we need a way to harmonize new-style and yaml config, for both startup and reload.

You mean can you add YAML config info in addition to setting up the config through the UI? I don't believe so unless you had a separate YAML file for the additional config items that your integration read and loaded in (e.g. outside of configuration.yaml).

The way config flow works is that you define a schema for a config, and then the UI shows it to the user to fill out based on the data types -> once the user submits, the backend sees a dictionary as you would expect from a YAML config and stores that to data in the config_entry. To handle YAML configs, there is an "import" flow that reads in the YAML and then passes that dictionary to the backend call that creates the entry, essentially mimicking a user doing the same.

So perhaps we should have a separate yaml configuration file for pyscript apps? @dlashua - what do you think?

There is one other option - We can make it so that if a user sets up through the UI, we can import just the apps section of the config on a reload and update the config entry. I would have to think about how that should work, but it is an option.